BBS Toolkit/BBS Toolkit.iso/wildcat/ffeed35a.zip/FFEED35.TXT

Text File | 1992-07-05 | 20KB | 498 lines

                                ForceFeed
                               Version 3.5

                             A DoorFrame Door
                     (Requires BRUN45.EXE In The Path)


                               Written by

                              Shawn McGill
                             The IMPROV BBS
                             [phone]
                                 USR/DS

                              Wildcat 3.01

                              July 5, 1992


I hate writing Docs, so I'll keep this as short and sweet as possible.
Forcefeed was conceived as a way to make my new callers download my
application file that is required for access to the IMPROV BBS.

Despite several screens telling them that I required them to download
the file, many still did not. Some because they weren't about to, but
some were simply new modemers, and didn't have the vaguest idea what a
download even was!

I decided to write a door that would force them to download the
application file, and Forcefeed was born. I use it as a menu hook off
the main menu. My new callers have only three choices: they can Press
[G]oodbye, [C]omment, or [A]uto-Application Download.

If they select "A", they enter this door, which leads them through the
download procedure, and sends them the file. If they successfully
download it, their security profile is upgraded, and the size of the
file is added to their user record KBytes total, as well as one file.

When they come back out of the door after a successful download, they
re-enter the system as a temporary user. If they did not successfully
download the file, they are given another chance. If the file is not
sent, no changes are made, and they're still looking at that 3-option
new user main menu.

WHAT'S NEW WITH VERSION 3.5:

Version 3.5 is updated to work with the new release of Wildcat (3.5).
The boys at MSI added a line to USERINFO.DAT, so version 3.3 of FFEED
will no longer work with it. I recompiled the door with a newer version
of DoorFrame that takes this added USERINFO.DAT line into account, and
all should be fine now.

Other than a couple of clean-ups to the original source code, no other
changes to FFEED were made. The newest features of version 3.3 are
outlined in the section that follows this one.

Version 3.5 expires on 9/1/92. This should be sufficient time to see if
it will run on your system, and if it meets your needs. After this time,
it must be registered.


WHAT'S NEW WITH VERSION 3.3:

With version 3.3, I moved the help file, and introduction screen
to external text files. The main reason I did this was to allow users
to be able to use the door for other things than simply forcing a
caller to download your application file. Most of the wording has been
made unambiguous enough that you could send about any file to your
callers. With the presidential elections coming up, you could have your
callers download your favorite candidate's speech, or you could have your
field representatives download new price sheets, or your users could
download your club's newsletter. You could start a "GIF of the Week Club"
and set up the door to send a features GIF file at the touch of a key!

You know your needs better than I do, of course, and I think with the
new generic screens, and the sysop-creatable help and introduction screens,
you should be able to find any number of uses.

I have included generic example screens that I use to upgrade new callers.
You can edit these screens to your own uses with any ascii text editor, but
they must be named HELPFILE.TXT and SENDFORM.TXT respectively.

In conjunction with the above-mentioned desire to make FFEED more useful,
I also made it possible to NOT change a user's security profile level.
If you were allowing users with several different security levels to use
the door before, they would have all ended up with the same level you
specified in the CFG file. No more! Sometimes you don't want to change the
level, and if you put "NOCHANGE" in the proper field in the CFG file now,
it will leave the user's level at whatever it was when he entered the door.

Of course, anything else in the "Upgrade Security" filed of the CFG file
will cause the program to change the user's level to that profile, just
as it did before.


WARRANTY:

None. I don't guarantee anything about this software. It may not even
run. It is running on several systems beautifully, including my own,
but I don't guarantee that it will on yours. I won't even guarantee
that it won't trash all your datafiles, and render your hard drive
unusable for the next three generations. All I can tell you is that
it hasn't hurt mine. In other words, you are using this software entirely
at your own risk. There are no warranties expressed or implied.

This door has been successfully run on a single node system under DOS,
on a three node system under Desqview, and a three node system under
4-DOS that I know of. During testing, files were successfully transferred
at speeds from 300 baud to 14,400.



CAVEAT:

One sysop I know says he uses DSZ and in particular the DSZLOG function
for recording upload and download stats with his com program. If you are
using the DSZLOG feature of true DSZ (not the zmodem that is built into
Wildcat or many terminal programs, but as an external protocol), then you
may want to set up your batch file differently than the one I have as an
example below. It is possible to set the DSZLOG environment variable at the
beginning of the DOORx.RUN, and release it before returning to Wildcat after
executing the door, but unless you increase the default environment size a
bit, you'll likely run out of environment space. ForceFeed needs to parse
the DSZLOG to determine if a download went through, and deletes the log
when it is finished.

There has also been an announcement that version 3.5 of Wildcat! will support
any protocols that use the standard DSZ.LOG format. I can only think that
this will cause some interference, so setting the DSZLOG environment variable
in the calling batch file, and releasing it when the door is done might prove
to be necessary to preserve FFEED's compatibility when WC 3.5 appears.

When I tried to set the environment variable for setting DSZLOG (explained
later) in the calling batch file, and then release it before returning to the
board, I ran out of environment space. By including the line:

           SHELL=C:\COMMAND.COM /P /E:2048

in my CONFIG.SYS, I was able to give my environment enough room to add the
SET DSZLOG= variable (explained later) from the DOORx.RUN file instead of
setting it in AUTOEXEC.BAT. Consult your DOS manual for a more detailed
explanation. Remember, any for any changes to your CONFIG.SYS file to take
effect, you must reboot your machine.


SETUP:

The setup of this door is a little unusual, but nothing too bad. The
following steps should have you up and running in no time (I hope!)...


Step 1.

Create a directory and unzip all the files in this archive into it.


Step 2.

Edit the following files:


    FFEED35.CFG

    The FFEED35.CFG file's name is not critical, since you will pass
    it to the program on the command line, but it must contain the
    following lines:

        Full path to DOOR.SYS
        The BBS's Name
        Sysop's First Name
        Sysop's Last Name
        Full path to USERINFO.DAT
        The name of your application file
        The security profile name to upgrade to (or "NOCHANGE")
        The Full path/name of the display file created


    Optionally, you can run FFINSTAL.EXE from your door directory, and
    this CFG file will be created for you.


    As you can see, it's much like every other door you
    ever set up, except that it looks for DOOR.SYS and USERINFO.DAT
    instead of CALLINFO.BBS.

    If you don't want a bulletin created of who's been
    successfully through the process, just put any filename on that
    line, and delete that file in your calling batch file when you
    return from the door. For example, you could enter BOGUS.TXT on
    that line, and make the last line of your calling batch file
    delete it every time it runs.

    You can also delete FFEED.DAT, which is created by ForceFeed to
    keep track of the door's transactions, if you don't want to
    maintain a display screen. I reset my ForceFeed door every month by
    simply deleting the FFEED.DAT file on the first of each month.



    A sample FFEED35.CFG file might look like this:


        C:\WC30\WCWORK\NODE1\DOOR.SYS
        The IMPROV BBS
        Shawn
        McGill
        C:\WC30\WCWORK\NODE1\USERINFO.DAT
        IMPROV.APP
        TEMPORARY
        C:\WC30\DISP\HELLO1N.BBS


    MAIN1.RUN

    This is the batch file that calls ForceFeed from your main menu
    "hook". Of course, it could also be run from the doors menu
    (DOORx.RUN), or from the File menu (FILEx.RUN) or Message Menu
    (MSG1.RUN), but that kind of defeats the purpose, doesn't it?

    Anyway you choose to run it, it's pretty straightforward.

        CD\FFEED (or whatever directory you created)
        FFEED35 FFEED35.CFG

    If you choose to enlarge your environment space as discussed
    above, and set the DSZLOG environment variable from the batch
    file, then your MAINx.RUN would resemble:

        CD\FFEED
        SET DSZLOG=C:\FFEED\DSZLOG.LOG (This sets the variable)
        FFEED35 FFEED35.CFG            (Run the program)
        SET DSZLOG=                   (This releases the variable)


    That's it! This file (if it's a "RUN") should be in your node
    directory. If you elected to make it a "BAT", then put it in
    your main WC directory (eg. C:\WC30).


    FFEED.DEF

    FFEED.DEF is a "dummy" file that is used to help determine if a
    download was successful. In the event a caller drops carrier
    before the transfer ever starts, DSZ does not create the LOG
    file that FFEED uses to determine the success of the transfer.
    Since the LOG won't exist at this point, it would be impossible
    to tell if things went wrong. This file must exist in the FFEED
    directory so that FFEED can tell if a caller dropped carrier
    before the download began.

    It should contain the name of the application file you want the
    door to send to the caller. One line, that's it.

    A sample FFEED.DEF file on the IMPROV BBS might contain:

        IMPROV.APP

    which is the name of my application file, and also matches line 6
    of your configuration file, you may notice.


    SENDFORM.TXT & HELPFILE.TXT

    These are the ascii text files that are sent to the caller to
    explain the purpose of the door, and if he hits the HELP option
    from the menu. You can read my examples that are included, and
    should be able to get a good idea of what these files are intended
    to convey.

    If you're using this door for something other than forcing
    registration downloads, you'll certainly want to edit them to suit
    your purposes. Just make sure you use the filemanes SENDFORM.TXT and
    HELPFILE.TXT. According to the DoorFrame Docs, these files can be
    ANSI color files, if you like, but I haven't tried that, and
    I don't know what a non-ansi caller would see. If it works, let me
    know <g>!

STEP 3.

Since FFEED uses Zmodem protocols, you must have DSZ.EXE or DSZ.COM in
your FFEED directory. I suppose you could simply have it somewhere on
your path, but I have only run this door with a copy of DSZ in the same
directory, and since it worked, I didn't try it anywhere else.

The final step is to edit your AUTOEXEC.BAT to include the following line:

        SET DSZLOG=C:\FFEED\DSZLOG.LOG

This is very important, as it activates DSZ's log function, and FFEED
uses this log to determine whether the caller successfully downloaded
the file you have specified. Remember that you must reboot after making
this edit for it to take effect.

You can either set this environment varaible in your AUTOEXEC.BAT file as
described here, or you can set it in your calling batch file, as discussed
in the "CAVEAT" section above, provided you have enough environment space
set up to hold it. It MUST be set, whichever way you decide to go, so that
FFEED will work properly.

The path in the SET statement above is intended to path to the
directory you created for ForceFeed. We want DSZ to create the log in
the ForceFeed directory, so make the above line point to the directory
you created for the ForceFeed files! The log file must be called
DSZLOG.LOG, though!!!

PLEASE READ CAREFULLY THE "CAVEAT" SECTION ABOVE IN REGARDS TO USING
DSZLOG AND THIS DOOR!!!

DSZ is the property of Omen Technology, INC, and in my opinion is the
finest transfer protocol driver available. It is available for download
on most every BBS in the country, if you don't already have a copy of it.
I encourage you to register your copy of DSZ, although this door will
run with the features available in the shareware versions.


AUTO-NOTIFICATION FEATURE:

I have made FFEED send a short text file each time it runs. This file
will be created in the default FFEED directory (the one you run the
door from). It includes the user's name, the time, and the date, and
whether or not he was successfully ForceFed. This text file is suitable
for importation into a message. The reason I did this, was so that anyone
who uses a program such as PostMaster could send themselves a message to
let them know that someone had used the door.

If you use a program such as PostMaster, you can send yourself (or your
userbase co-sysop, for example) a message using this text file. This
file is called LASTCALL.TXT. It is overwritten each time ForceFeed runs.

A batch file such as the following would send me a message each time the
door runs:

   CD\FFEED
   SET DSZLOG=C:\FFEED\DSZLOG.LOG
   FFEED35 FFEED35.CFG
   SET DSZLOG=
   CD\WC30
   POSTMSTR /I:C:\FFEED\LASTCALL.TXT /T:SYSOP /F:DOOR /S:FFEED ACTIVITY /P
   DEL C:\FFEED\LASTCALL.TXT

The reason I delete the LASTCALL.TXT file after each run is because if a
user just went into the door, and came right back out, a new LASTCALL.TXT
wouldn't be generated, and PostMaster would send you a second copy of the
previous caller's notification. If you delete LASTCALL each time, and a user
goes in and out without trying to dl your app, PostMaster simply won't find
the source file, and no message will be sent.

Please consult the PostMaster Docs for an explanation of the various command
line switches used by PostMaster.

PostMaster is a great Wildcat! utility written by Dave Cody of Boardwalk
Software. It is copyright 1992 by Dave Cody. PostMaster is available for
download on many Wildcat systems, or directly from Dave Cody's board,
The Boardwalk at [phone].



RECAP:

To recap, the following files should be found in your Door directory:

        FFEED35.EXE
        FFEED35.CFG
        HELPFILE.TXT
        SENDFORM.TXT
        Your Application File
        DSZ.EXE or DSZ.COM
        FFEED.DEF

The Batch file that you call the door with should be in your main WC30
Directory if it's a ???.BAT file, and in your node directory if it's a
???.RUN file.



HISTORY:

The original Catpatch version was released on April 5, 1992. It had
some problems on non-standard platforms, probably because of the
Catpatch routines, themselves.

Version (3.1) was released on April 26, 1992. I rewrote the door, this
time using DoorFrame routines. This was done in an effort to give it
some improved I/O routines, and wider compatibility. Non-standard IRQ's
are now supported, along with much higher baud rates.

Version (3.1a) was released on May 6, 1992. Nothing was changed about the
door itself, but I updated the docs to include an explanation of
the need for the FFEED.DEF file, which was left out of the previous
DOCS. I also added a warning about FFEED's use of the DSZLOG function.

Version (3.2) was released on May 29, 1992. I added the ability to interface
with programs such as PostMaster by having ForceFeed create a small text
file called LASTCALL.TXT which contains a message telling if a user either
did or did not successfully download the app file. By using a program such
as PostMaster, you can send yourself or your userbase co-sysop a formal
message notifying of FFEED activity. This saves your having to go looking
for the information. It will be "ForceFed" to you! <g>... LASTCALL.TXT is
overwritten each time the door runs, so if you choose not to use this
feature, you can just ignore it, and the file will never grow any bigger.

Version (3.3) was released on June 5, 1992. I added the capability to NOT
change a user's security level by putting NOCHANGE in the upgrade profile
level in the CFG file. I also changed the internal screens to more
generic wording and moved the SENDFORM.TXT and HELPFILE.TXT screens to
external ascii text files to allow the sysop to use the door for a wider
range of possible applications.

Version (3.5) was released on July 5, 1992. FFEED was recompiled with an
updated version of the DoorFrame routines. Since Wildcat added a line to
the USERINFO.DAT file with version 3.5, I had to change a line or two of
code, and use the newer DF routines to deal with this change. No other
changes in the program were made, except to make it compatible with the
new Wildcat release. This version will not work with versions of Wildcat
earlier than version 3.5!



SUPPORT

I will support this door through my BBS, The IMPROV at [phone]
(USR/DS). I am a member of ThrobNet (known as "Al Bundy"). I also
call the MSI Support Board on a regular basis.

REGISTRATION

This door will expire on 09/01/92. That should be sufficient time to
see if it will run on your system, and whether it meets your needs.
After a reasonable evaluation time, you must either register it, or
delete it from use on your system.

Registration is $20.00.

When you complete the registration form, I will pre-register you on my
BBS, and make your registered copy available for you to download when
it's ready. Future updates will also be made available for you to download
as they are released. It'll be up to you to call in from time to time
to check for updates.

Those who register will receive a copy without the expiration routines,
and their name and registration number will be included on the initial
intro screen. Registered users will also be entitled to any future
versions of this program, which will be available for download on my
BBS at V.32 & HST speeds (USR/DS).


------------------------------ Tear off Here ----------------------------------


                            ForceFeed Registration
                     v 3.5


Name:________________________________________


BBS NAME:____________________________________


BBS PHONE:___________________________________


Mailing Address:______________________________________________


City:_____________________________________ State:_____________________


Date:_______/_______/________


Please enter a name so I can pre-register you on my BBS. I check my P.O.Box
about once a week, so be patient... <g>.. I will have your copy ready for
download the next day after I receive this form and your payment.



    NAME:_____________________________________

    PASSWORD:_________________________________

    D.O.B:_______/_______/_______


Registration: $20.00  Please check one:   Check_____    Money Order_______


Make Payable to:

    Shawn McGill
    P.O.Box 6148
    Louisville, KY
        40207

Thanks for supporting Shareware!